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REMARKS 



Claims 2-3, 8, 12, and 19-20 were rejected as indefinite. 
Applicant requests reconsideration. The claims have been 
accordingly amended. The term "identifier" was removed from the 
claims. In reading the claims, there are originating, proximal, 
distal, source, and destination caches, having respective URLs and 
IPA. To aid understanding and resolution, caches, URLs and IPAs are 
referenced. 

Claims 1-4, 6, 8, 9, 11, 12, and 14-20 were rejected as 
unpatentable over Jordan in view of Garcia, Claims 7, 10, and 13 
were rejected as unpatentable over Jordan in view of Garcia in view 
of Bertis. Applicant requests reconsideration. Applicant now 
responds to respective examination a-f comments. 

a) The examiner states that claim 1 does not reference the tri- 
reference association. Anyone skilled in the art must realize that 
in order to send a message to a destination through the web, the 
destination IPA must be included. The tri-ref erenced information 
includes the originating URL, the source IPA, and the destination 
IPA. That is, the routing information sent must necessarily include 
the originating URL, the source IPA, and the destination IPA. 

b) The examiner states that Jordan transmits routing information 
(such as source address, destination address, forwarding address, 
next hop address as disclosed upon request) . What is strikingly 
missing from this list is the necessary originating URL. 



-13- 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



c) The examiner states that transmitting to one destination is not 
broadcasting and that claim preambles do not limit the claims. If 
the preamble is not a limitation, then the reference to 
broadcasting in the preamble, respecting claim 1, seems misplaced. 
Surely the communication to one destination cache is a minimal, 
point-to-point broadcast, but a broadcast nonetheless. Claims 11 
and 14 particularly claim repeating the communication, which 
perfects a wide-area broadcast. Also, the destination can build a 
forwarding and routing table from the receipt of a plurality of 
routing information. Broadcasting and table maintenance are the 
uses of the claimed tri -reference communication. Applications and 
uses are spelled out in the preamble, not as limitations, but as 
uses and applications. While uses and applications are not recited 
element limitations, they nonetheless go to obviousness, in that, 
the problem solved is relevant, to wit, building a URL- to-distal 
cache routing table through broadcasting. Hence, applicant's 
discussion as to obviousness and the problem solved brings in 
discussion of broadcasting for forming the distal routing table. 

Applicant devised tri -reference routing information to solve 
the prior art problem. The tri -reference routing information 
communication is the solution, to solve the problem of distal table 
maintenance. It this regard, Jordan and Garcia have no commonality 
with which to arrive at the present invention. Communication of 
routing information by Jordan and the maintenance of table in 
Garcia are not related in any regard, and the combination of them 
does not suggest the invention in any regard. The examiner has 
simply taken isolated features and combined them based upon 
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forbidden hindsight reconstruction. Jordan does not communicate the 
tri -reference information. And Garcia does not receive the tri- 
reference information nor use tri -referenced communicated routing 
information to maintain tables. 

d) The examiner first indicated that the claims do not recite a 
table. Hence, claims 19 and 20 were added. Applicant is claiming a 
method of communicating tri -referenced routing information that can 
be broadcast and that can be used to build routing tables in 
receiving distal caches. The examiner states that Garcia discloses 
broadcasting the routing update messages comprising routing 
information. Yet the examiner did not recite what exactly is that 
information, which particularly relates to Internet Protocol packet 
routing in the case of Garcia. Furthermore, Garcia does not 
communicate tri -referenced routing information that includes an 
originating URL. Both Jordan and Garcia do not communicate tri- 
referenced routing information and both particularly do not 
communicate the originating URL. Without source IPA, originating 
URL, and the destination IPA, combined as routing information, 
which may incidentally be wide-area broadcast and used to build 
routing tables, Jordan and Garcia cannot possibly suggest the claim 
inventions . 

e) The examination's inability to recognize the invention, led the 
applicant to assist the examiner though the inclusion of claims 19 
and 20 wherein the tri-ref erenced routing information is actually 
used to build routing tables. Prior to adding new claims 19 and 20, 
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routing tables were not claimed. Applicant will assist the examiner 
as necessary to fully gain understanding of the inventions and the 
prior art. 

f) The terms hop, path, link, are well understood by those skilled 
in the art. There is no ambiguity. 

The claims were rejected in part because the claims do not 
recite intended applications of the method steps for broadcasting 
associated routing information or recite arguments used in support 
of non- obviousness . These rejections are misplaced. The examiner 
states, on page 4, "In other words, the features upon which 
applicant relies, (as in applicant's arguments), are NOT recited in 
the rejected claims". This is a common perfunctory rejection often 
correctly used by examiners in anticipation rejections, but so 
often misplaced in the context of obviousness rejections. 

In claim 1, applicant claims a method of broadcasting, which 
method is executed solely at the proximal cache, AND NO MORE . This 
claim clearly sets the reference perspective as being the proximal 
cache at the proximal IPA. As such, a potential infringer has to 
notice that a proximal cache, so broadcasting, that is merely 
broadcasting without regard to creating a forwarding and routing 
table at a destination, perfects the method and is covered by the 
claim. With this broadcasting method, a routing and forwarding 
table at the destination can then be maintained at a distal cache. 
As such, applicant claims the method of broadcasting only in so far 
as the execution is exclusively performed at the proximal cache. 
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There is no requirement that claim 1 also includes language as 
to the intended uses or applications of this broadcasting method or 
requirement that this claim claims the benefits of this 
broadcasting method, as the examiner incorrectly suggests. An 
obviousness determination is focused upon whether or not the 
claimed combination is obvious. The determination of obviousness 
goes to both the solution as in part claimed in claim 1 and the 
problem solved as stated in the argument . As to the solution in 
part, the combination of claim 1 has not been rejected as 
anticipated, but rejected for obviousness. Anticipation can be 
determined by an element-by-element comparison. Applicant did not 
address an anticipation rejection, where elements must be recited 
in the claims and not found in a single prior art reference. If 
applicant had argued that claim 1 was not anticipated because the 
prior art does not teach a destination routing table in 
combination, then the examiner's assertion would have been correct, 
and the routing table should be recited in the claims. However, the 
rejection is one of obviousness that brings into consideration a 
whole variety of related issues, such as, a long felt need without 
solution, and of course, the prior art problems solved. Surely, the 
examiner would not suggest that the claims must specifically recite 
the number of years that the prior art had such a long felt need, 
or necessarily, recite the prior art problems solved, yet these two 
things do support a non-obviousness determination. Arguments that a 
claimed invention is not obvious need not be recited in the claims. 
It is simply enough that the combination not be anticipated, as 
indicated in the present record, and that the combination of claim 
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I, not be obvious. It is simply enough that the claimed 
broadcasting method steps in combination not be suggested, yet be 
useful . The reasons why a claim combination would not be obvious 
need not be recited in the claims. The examiner's basis for 
rejection because applicant's arguments are not found in the claims 
is without merit in the present obviousness determination context. 

The claims are patentably distinct as written. New claims 19 
and 20 add another step to claims 1 and 8 respectively of storing 
the association in the destination cache at the destination IPA, 
whereat a forwarding and routing table can be maintained. Hence, 
the use of the claimed combination of the broadcasting method of 
claim 1 then enables the creation of forwarding and routing tables 
at the destination IPA, and hence, enables the migration of routing 
information containing associations between URLs and source web 
cache IPAs subsequently stored as routing items in forwarding and 
routing tables at destination IPAs. Significantly, the claim 1 
steps provide a method of broadcasting routing information that can 
then be used by other distal caches for accomplishing the migration 
of forwarding and routing tables. Claim 1 claims a broadcasting 
method and not the creation of forwarding tables as now claimed in 
new claims 19 and 20. Surely, this unanticipated and unobvious 
broadcasting method is of some value. 

From a practical perspective, the examiner should realize that 
networks have distributed caches that can be manufactured by 
various entities. Claim 1 only covers a broadcasting cache that is 
the proximal cache, and hence, covers a necessary element to 
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forwarding and routing table migration within an entire network. 
Claim 1 covers a necessary novel core of the invention because, 
without this broadcasting of routing information, a distal 
forwarding and routing table cannot be maintained by a proximal 
cache. Hence, claim 1 focuses on a core point of novelty while 
providing clear notice of the scope of the claim. Other systems do 
have caches, and do have forwarding tables, and do have routing 
tables, but do not broadcast tri-ref erenced associated routing 
information. Hence, the focus of claim 1 is directed to a necessary 
point of novelty. The threshold point of novelty is the 
broadcasting of tri-ref erenced associated routing information. This 
broadcasting does not include process steps occurring at the 
destination cache, so that one can determine from claim 1, which 
caches within a network are covered by claim 1, and which ones are 
not. As such, the process steps of claim 1 are executed only at the 
proximal IPA, give clear notice as to what would infringe, and 
focus the examination of this case. This claim 1 strategy provides 
clear notice, covers a necessary point of novelty, and focuses this 
examination on to that the point of novelty, which is the 
broadcasting method of claim 1. 

As such, the present invention of claim 1 serves to solve the 
problems of maintaining a network of cooperative caches through the 
migration of forwarding and routing tables by broadcasting tri- 
ref erenced associated routing information. The present invention 
solves the problem of routing table migration by broadcasting from 
a first proximal cache to a second destination cache at a 
destination IPA routing information that associates a URL-Id and a 
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third source IPA . These first, second, and third caches are clearly- 
referenced in claim 1. The associated information includes a tri- 
referenced destination IPA, originating URL, and a source IPA. This 
association is recited in claim 1. Claim 1 is particularly recited, 
novel, unobvious, and useful. 

The destination cache need not necessarily store the sought 
after web content data, but only maintain routing items that define 
where the web content data may ultimately be located through 
routing and forwarding, and ultimately stored among the cooperative 
caches. The web content data specified by the URL can be 
alternatively cached in and retrieved from a source cache for 
improved distributive web content data caching. As such, the 
present invention solves the problem of maintaining cooperative 
cache forwarding and routing tables by broadcasting tri -referenced 
associated routing information. The tri -referenced associated 
routing information including the URL, source IPA, and the 
destination IPA, can then be used to create a forwarding and 
routing table in any arbitrary distal cache, so as to migrate the 
forwarding and routing table information about the cooperative 
caches. This migration occurs without regard to load balancing, 
polling, frequency monitoring, or the mere transmission of URL 
requests from any one cache to another cache as in Jordan. 

Applicant appreciates that many web features are found in 
various methods operating on various caches in cooperative systems, 
and that, the examination can become quickly confused if one is not 
careful to focus on the broadcasting steps of claim 1 in reference 
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to any sole proximal cache, as in Jordan. Applicant was well aware 
of this potential problem. To make the examination process as 
focused and as convenient as practicable, claim 1 is directed only 
to the minimal novel broadcasting steps executed by a single lone 
proximal cache, so that, operational steps by any other lone cache, 
such as in Jordan, can be quickly compared for novelty. Does this 
prior art reference, Jordan, teach or suggest a single cooperative 
proximal cache executing these tri- referenced associated 
broadcasting steps? This determination is limited in scope to aid 
in the examination process. When viewing Jordan, a like reference 
perspective to a "proximal cache" serves to quickly clarify the 
comparison and highlight the points of novelties. 

That is, the examiner should compare apples to apples, and any 
lone cache in Jordan can be compared to the proximal cache of claim 
1. However, because all of Jordan's caches operate in like manner, 
any one cache in Jordan may be used for comparison. In this regard, 
the migration and creation of forwarding and routing tables can be 
had through a unilateral tri-ref erenced associated broadcast 
communication from a broadcasting proximal cache as in claim 1. A 
distal cache can then use this broadcast communication for building 
a forwarding and routing table as recited in claims 19 and 20. For 
example, when the destination cache receives a URL request, the 
request can be routed and forward to the source cache and not the 
originating cache. As such, claim 1 and claim 19 highlight 
respective bifurcated functions for migrating forwarding and 
routing tables. Jordan relies on like caches whereas the proximal 
cache of claim 1 and the distal cache of claim 19 rely on a 
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cooperation between differently operating caches, yet another clear 
distinction between Jordan and the present invention. 

Jordan teaches a load-balancing network of like cooperative 
caches that store web content data and maintain caching tables . 
Jordan does not solve the problem of migrating forwarding and 
routing tables about a network of caches. Jordan does not use the 
claim 1 solution of transmitting from a proximal cache to a 
destination cache tri- referenced routing information associating a 
URL with a source IPA of an alternative source storing or pointing 
to where the URL's web content data may be subsequently retrieved. 
In so doing, the invention of claim 1 serves to enable the 
migration of the forward and routing information about the 
cooperative distal caches that can then create forwarding and 
routing tables arbitrarily anywhere in the cooperative network. 

Jordan teaches that when a cache is overloaded by a URL 
request, the URL request is directed to another destination at a 
destination IPA, so that the destination, that may store the web 
content data, can then function as a new alternative source. As 
such, the destination can retrieve the web content data, store it 
locally, and then respond to URL requests for the web content data 
so as to load share. As such, the destination and source are one in 
the same. Jordan does not solve the problem of migrating forwarding 
and routing tables among cooperative distal caches. Jordan does not 
suggests the invented solution of broadcasting to a destination 
distal cache tri -referenced routing information associating the 
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destination IPA with a URL indicating that web content data can be 
found in an alternative source cache. 

In Jordan, a proximal cache at a proximal IPA receives a 
request for URL web content data from an originator or client 
browser. When the proximal cache at the proximal IPA is overloaded, 
the proximal IPA redirects the original request to a destination 
IPA also storing the web content data. The request is forwarded to 
a destination as an alternative source. The request contains an 
association between the requesting IPA and the URL of the 
originator originally firstly storing the requested web content 
data. Then, the destination cache stores the web content data to 
serve URL requests. The destination retrieves the URL web content 
data, stores it locally, and updates its caching table indicating 
it has stored this URL web content data. Jordan teaches load 
sharing. Jordan does not teach a method of broadcasting tri- 
referenced routing information, including an association between 
URL- Id and an alternative source of the URL- Id web content data and 
a destination, but rather directs the URL request to an unloaded 
server storing the sought after URL data. Jordan does not teach a 
method of broadcasting an association of a source with a URL to an 
arbitrary destination that can then construct and maintain a 
routing and forwarding table. 

Jordan teaches a load-balancing web content data caching system 
that maintains a logical central directory for locating where 
requested web data is stored, preferably in the least loaded cache. 
(Col 7 lines 60-65) . In Jordan, there is a guarantee that the owner 
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indicated in the directory does store the sought after web content 
data. By contrast, the present invention makes no such guarantee, 
as the routing information merely provides a direction through 
which a request could be forwarded or routed until a source cache 
is eventually reached that does store the sought after web content 
data specified in the URL request. The broadcasting of claim 1 
provides the routing information, including the destination IPA, 
the URL, and the source IPA, and not the web content data. 

The present invention provides for the broadcasting of routing 
information from a proximal IPA. The routing information at the 
proximal cache at a proximal IPA location is a tri- referenced 
association associating the destination cache at a destination IPA, 
and a source cache at a source IPA, and the URL. The associated URL 
request for web content data originally provided at a originating 
URL IPA is an implied fourth location. The physical locations are 
the proximal IPA, source IPA, the destination IPA as particularly 
stated in claim 1, while a fourth location of the original URL IPA 
location is also inferred. This specifically required tri- 
referenced association of the destination IPA, source IPA and URL, 
as recited in claim 1, is essential to understanding the novelty of 
claim 1 that then enables the migration of forwarding and routing 
tables. The destination IPA, originating URL, and source IPA 
association includes routing information associating a source IPA 
and the URL during broadcasting, which then enables the building of 
a forwarding and routing table at the destination distal IPA. 
Jordan does not have this tri -referenced association or the 
capability of migrating forwarding and routing information through 
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unilateral broadcasting. Jordan does maintain a caching table, 
which can be used to forward URL requests. However, the caching 
table is not maintained by virtue of receiving unilateral broadcast 
tri- referenced associated routing information. The caching table is 
not maintained by virtue of receiving unilateral broadcast routing 
information because, in Jordan, at least two of the claimed tri - 
referenced IPA locations, if not all three, are the same locations. 
In Jordan, the source and destination are one in the same, which 
receives a request, retrieves the URL data, updates its caching 
table, and becomes the alternative source, and hence, the 
limitation to only caching tables indicating exactly where is 
stored the requested web content data. 

In view of the abstract of Jordan, a "request" indicating a 
requester at a requester IPA and indicating the "object", that is 
the requested URL web content data, is "forward" directly to 
another cache, so that the "requests" are shifted, that is, forward 
to another cache also storing the sought after web content data. 
Jordan does not use routing in any regard, as the examiner 
incorrectly suggests. Jordan migrates web content data and forwards 
requests when overloaded. Jordan's shifting by forwarding requests 
perfects load balancing among caches. As such, Jordan maintains a 
directory as a correctly named caching table of all caches storing 
the sought after web content data for forwarding when overloaded. 
That is, all of Jordan's caches are merely source caches sharing 
loads by forwarding requests. There is a difference between a 
caching table and a forwarding and routing table. A caching table 
points directly to alternative source caches having the stored 
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data. A forwarding and routing table points to another location 
that may or may not have the stored data, but ultimately indirectly 
points through a path along which a request is routed and 
forwarded, hopping from one cache to another, to where the data may 
be ultimately found. When a proximal cache is overloaded in Jordan, 
the proximal cache sends the URL request, which is not used as 
routing information, to an alternate cache location, at an 
alternate destination. (See Figure 3) As such, each proximal cache 
monitors the frequency of the requests, and if overloaded, each 
proximal cache searches its caching table directory to find other 
caches storing the same web content data, and forwards the request 
to the alternate source cache. In this manner, load balancing and 
web content data sharing is achieved. 

Jordan forwards a URL request to a destination source cache, 
being both a destination and a source. Each cache in Jordan is a 
proximal cache, a destination cache, and ultimately a source cache, 
each maintaining a respective like caching table. The communicated 
URL requests or polling inquiries are simply not routing items 
having a tri- referenced association between a destination IPA, a 
source IPA, and a URL enabling a migration of forwarding and 
routing tables. The polling in Jordan is a bilateral communication, 
and not a unilateral communication. Jordan does not communicate 
from one proximal cache to a destination cache indicating that data 
is available through, but not necessarily at, yet another source 
cache. Jordan's caches do inquire through multicast polling where 
the information is stored for maintaining the caching table. When 
stored at the destination, the proximal overloaded cache sends the 



-26- 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
21 
28 



URL request to the destination to load share. In Jordan, there is 
no tri- referenced associated routing information broadcast from a 
proximal cache to a second destination cache indicating a direct 
forwarding or indirect routing path to where the web data is stored 
on a third source cache. In Jordan, there is no routing information 
whatsoever, but rather, mere requests to send web content data to a 
requester or polling inquiries. In Jordan, an overloaded proximal 
cache searches its caching table directory, and then communicates 
and forwards the request from a proximal cache to a distal 
destination also serving as an alternative source cache. As such, 
Jordan does imply operation among three locations including a 
requester, an overloaded cache, and an underloaded cache. The 
operation in total does involve three locations, a requester, a 
proximal cache, and a destination source cache. However, the 
information consists of mere requests, inquiries, and does not 
point directly or indirectly to yet another third alternative 
source cache of the web content data. In Jordan, the destination 
and source are one in the same. The requests may be also used as 
the inquiries as to whether or not the web content data is stored 
at a distal cache. Hence, Jordan's communicated information is 
different. For maintaining the caching table, Jordan's information 
may include URL requests, the requester, and the destination, but 
not URL requests, the destination, and another source. The polling 
inquires would not include the alternative source as with the tri- 
referenced associated routing information of claim 1. Jordan 
provides for mere URL requests or inquiries, whereas the present 
invention broadcasts actual tri-ref erenced routing information. The 
information is different, and hence, Jordan does not anticipate, 
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and information communicated ultimately serves different purposes, 
such as load sharing using caching tables as opposed to routing 
information migration, and hence, the arguments as to 
nonobviousness . Jordan solves the problem of load balancing using 
forward requests, polling inquires, and caching tables whereas the 
present invention solves the problem of migrating routing tables 
and does so by broadcasting tri-ref erenced associated routing 
information. With different problems solved, different objectives, 
and different solutions, Jordan does not remotely suggest the 
present invention. 

Specifically comparing apples to apples, Jordan teaches 
multicasting where a cooperative cache multicasts URL requests or 
inquiries to other caches. (Col 8 line 1) These URL requests may 
function as simple inquiries, such as, "do you have this 
information" , and the answer may be w y es /" indicated by merely 
sending the web content data in response. In so doing, each cache 
polls the remaining caches to maintain the caching tables. Jordan 
maintains a caching table by polling caches through bilateral bi- 
ref erenced communications. The present invention broadcasts 
unilateral tri-ref erenced routing information, so that, distal 
caches can maintain routing and forwarding tables. Jordan 
bilaterally multicasts bi-ref erenced unassociated inquires to 
maintain caching tables in proximal caches. The present invention 
unilaterally broadcasts tri-ref erenced associated routing 
information for maintaining forward and routing tables in distal 
caches. The two processes are completely different serving 
different objectives for solving different problems. 
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Jordan is clear and teaches load balancing. "Direct requests 
155 are sent from the clients ... to cache server". (Col 5 line 55) 
"If an actual load imbalance is identified ... the load monitor 
initiates a shifting of forwarded requests from the overloaded 
cache to ... less loaded servers". (Col 6 line 3) "if the owner is 
currently overloaded . . . the load monitor finds an underloaded 
cache ... and assign it as the new owner of the requested object". 
(Col 6 line 63) "The ownership information for the object in the 
caching table is updated". (Col 6 line 64). "The request can be 
forward ... to the new owner". (Col 7 line 3) 

The examination states that Jordan's request includes source 
address, destination address, forwarding address, next hop address, 
as disclosed in the request to an arbitrary cache or destination 
upon a cache miss wherein the new entry is created for the object 
in the caching table a routing or forwarding table (Col 6 L50-67, 
and Fig 2a) . 

Is that really so? A search of specification reveals that the 
term "HOP" is not found at all. A search of the summary and 
preferred embodiment reveals that the term "route" is not used at 
all. Yet, to the examiner, it is apparently clear from these 
apparent phantom words. Within this cited text, none of these terms 
are mentioned at all, yet, this section is cited as the basis of 
the rejection. This is remarkable. Applicant appreciates that the 
technology is complex and involves many caches at many different 
locations serving different uses while communicating different 
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types of information. Nonetheless, precise and careful reading is 
required to fully understand the differences between Jordan and the 
present invention. 

The caching table shown in Fig 2a of Jordan includes objects 
(the URL) and "Ownership" that is, the caches A, B, C storing the 
web content data. Such specific A, B, and C caches are not 
arbitrary, as indicated by the examiner, but indicate exactly where 
the data can be found and exactly where the request can be 
forwarded for load balancing and sharing. It appears the examiner 
reads more in Jordan than what is really there. 

The plain full text does not read as the examiner indicates. 
"FIG. 3 shows an example of a logic flow for steps taken by the 
load monitor 120 in response to a request 125 from a cache server 
150 because of a cache miss. As depicted, in step 201, it checks to 
see if the requested object/partition can be found in the caching 
table. If not, in step, 202, a new entry is created for the 
object/partition and a cache server is assigned as its owner. After 
the entry is located in the caching table, in step 203, the 
forwarding frequency 1011 is updated, e.g., incremented by 1. The 
load monitor then examines the load table 102 to see if the owner 
is currently overloaded (and that the forwarding frequency 1011 is 
a significant contributor thereto), in step 204. If yes, in step 
205, the load monitor finds an underloaded (or less loaded) cache 
server and assign it as the new 10122 (or shared) owner 10122 of 
the requested object. The ownership information 1012 for the object 
in the caching table 101 is updated accordingly. Those skilled in 
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the art will appreciate that the logic flow could comprise a shared 
10123 or hierarchical ownership 1012 in the caching table 101 or 
other data structure employed. The request (possibly with a copy of 
the requested object) can then be forwarded 125 to a new sole 10122 
(or shared 10123) owner, in step 206. Alternatively, the new owner 
can be requested to obtain 115 an object copy from the originating 
object server, e.g., via the Internet 110." (Col 6 lines 50-66). 

As such, the examiner incorrectly cites a specific section of 
text standing for the proposition that "On the other hand, Jordan, 
in its clear context, explicitly teaches the process of 
transmitting routing information, (such as source address, 
destination address, forwarding address, next hop address, as 
disclosed in the request) to an arbitrary cache or destination upon 
a cache miss, wherein the new entry is created for the object in a 
caching table, or routing or forwarding table." In discussing 
Jordan, "in its clear context", the examiner uses the terms such as 
"source address", "destination address", "forwarding address", 
"forwarding table", yet a simple cursory examination of the cited 
text upon which the examiner relies, teaches no such things nor 
uses any of these terms. Where are these terms in the cited text? 
How possibly could one make this apparent leap, but through some 
kind of tortured reasoning? These terms used by the examiner are 
not in the cited text, nor suggested in any regard, yet asserted by 
the examiner, as "clear". This is remarkable. The record of the 
present prosecution is becoming so distorted by the examiner's 
unsupported assertions, that this record is quickly becoming, in 
and of itself, a strong indicator of nonobviousness . 



-31- 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 



Jordan should be viewed from the exclusive perspective of a 
lone proximal cache, as dictated by the structure of claim 1 of the 
present invention. Jordan multicasts different information, that 
may be simple URL requests indicating a requester and the URL to a 
source of the URL data. This is opposed to broadcasting routing 
information associating an alternative source and a URL with a 
destination IPA, which does not even request the URL data. In 
Jordan, the URL request is communicated to a different location, 
that is, directly to a source of URL web content data for 
retrieving the URL content data. This is opposed to communicating 
to a destination cache that merely receives the routing information 
indicating an alternative source, which communication can then be 
used to build a forwarding and routing table. Jordan solves a 
different problem that is one of load balancing among like caches. 
This is opposed to solving the problem of migrating routing 
information for the purpose of building routing and forwarding 
tables in different arbitrary distal caches. With all kind due 
respect, Jordan does not remotely suggest the prevent invention. 

Jordan multicasts polling bi- referenced inquiries from a 
proximal cache to destination caches that affirmatively respond in 
bilateral communications for maintaining a caching table in the 
proximal cache , which caching table is then used for forwarding URL 
requests to those destinations storing the URL data when a URL 
request frequency at the proximal cache is high for load balancing . 

The present invention of claim 1 broadcasts from the proximal 
cache to destination caches tri -referenced routing information in a 
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unilateral broadcast communication, where the routing information 
associates a source IPA with stored originating URL data or stored 
additional routing information to a source of stored URL data along 
with the destination IPA, so as to enable the maintenance of 
forwarding and routing tables in the destination caches as in 
claims 19 and 20. 

Jordan relies on like caches all with like caching tables and 
with like frequency monitoring, whereas the proximal cache of claim 
1 and the distal cache of claims 19 or 20 rely on a cooperation 
between differently operating types of caches. Jordan does not 
suggest such a bifurcated cache function. The present invention is 
not required to poll other caches. The present invention does not 
require load monitoring. The present invention does not require 
multicast bilateral communications. The present invention does not 
maintain limited caching tables restricted to a few caches for 
simple load sharing only among them through forwarding URL 
requests. The present invention enables the building of generalized 
routing and forwarding tables in arbitrary destination distal 
caches regardless of what web data is stored on the distal 
destination caches. The present invention enables cooperative 
caching about a network of cooperative caches without regard to the 
frequency of URL requests at any one cache. Jordan does not have 
these benefits. The alternative distal source cache may store and 
source the URL web content data through directed forwarding 
requests or the alternative distal source cache may indirectly 
point through hop routing to yet another more remote distal 
alternative source cache storing the URL web content data, as 
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indicating the equivalence between forwarding and routing, enabling 
any number of routing hops to locate the sought after web content 
data stored in any one of any number of cooperative caches disposed 
anywhere within a network. The present invention is a significant 
advancement in the art and enables a comprehensive generalized 
network-wide distributive caching solution. 

The cited references do not teach or remotely suggest 
broadcasting of tri -referenced associated routing information from 
a proximal cache to a destination distal cache, with the routing 
information associating URL web content data at an originating URL 
with an alternative distal source cache. The tri -reference routing 
information minimally includes: 1) Source IPA (where the web 
content data is cached) ; 2) Origination URL (identifying the 
original web content data); 3) Destination IPA (where the source 
IPA and Originating URL association are communicated for building 
at the destination IPA routing and forwarding table that directly 
or indirectly point to the URL web content data at the source IPA) . 
The proximal IPA is a fourth. bit of routing information. However, 
sometimes the proximal cache and the source cache are one in the 
same. When the destination cache receives this routing information, 
associating the original URL with the source IPA, a routing can be 
created in the destination cache associating the source IPA with 
the originating URL, so that, when a URL request is received by the 
destination cache, the destination can forward (or reroute) the 
request using the association between the request's URL to the 
source IPA, rather than the originator at the originating IPA 
originally storing the web content data indicated by the 
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originating URL. Hence, the tri-ref erenced information can be used 
to build a routing table in a destination cache. When the proximal 
cache at the proximal IPA broadcast the routing information to many- 
destination caches, the network of cooperative caches can each 
build a forwarding and routing table for improved web 
communications. Such broadcasting of this specific tri-ref erenced 
associated routing information then enables the maintenance of 
forwarding and routing tables in arbitrary destination caches for 
forwarding and routing URL requests about a network of cooperative 
caches. Allowance of the claims is requested. 
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